"In the previous message, Gene Spafford said..." > > > > I think that the biggest pro of full disclosure, is that it get's people > > off their butts and gets a good solution or patch that much faster. > > I have yet to see evidence of this. Based on my conversations with personnel > at various computer companies, the only thing full disclosure seems to do is > (sometimes) encourage them to release bug fixes without quite as much testing. > This sometimes leads to patches that don't completely fix the problem. That > is not a "good solution." > > If anyone can provide me with verifiable evidence that full disclosure results > in faster production of patches of good quality, I would be very interested in > seeing it. Otherwise, it's just wishful thinking. This has been beat to death, and the consensus was very apparant. Obviously we have a group of people who think They Know Best(tm) and have taken measures to *ignore* the consensus and ensure this sharing of info does NOT happen for personal or egotistical reasons. Pretending the consensus does not favor free flow does not make it so. Spaf, you have been very helpful in the past, and only one funky/out-of-line thing I can think of is attributed to you, but this is not one of those helpful times. Lets see some verifiable evidence that your obscurity postion is such a Great Thing. Anyway, here we go again: Yes, this could be called a flame, delete and go to next message now if you don't care about this isue. ------------------------ The DENIAL of crucial security related information is what needs verifiable justification - not the free flow. At least in a free society (or is it only free when it fits a personal agenda?) Hell, you Obscurity folks won't even share it with admins at NIC registered sites (you sure as hell have not with me), so protection of sites (other than those run by folks in the 'inner circle') is not the prime motive, as I see it, rather one has to suspect, at least in some cases, the obscurity game is one of stroking egos. And "patches of good quality" is a subjective thing - if it closes the hole, or even makes it harder to exploit than before, its "good quality", EVEN IF IT DOES NOT COME FROM THE VENDOR, cuz its better than NOTHING or being fed a bunch of patronizing platitudes. One failed patch does not justify trashing the whole system - thats like banning the sale of gasoline cuz an arsonist used it, or banning pickup trucks cuz one manufacturer didn't do his gas tank layout very well (well, mebbie in the eyes of those who think government should be a wet nurse it might). So, how about YOU or the security thru obscurity crowd providing *verifiable* evidence that security through obscurity makes the net safer and all our sites more secure and safe in not only the short, but long term? Show us how the idea of limiting the information to a 'chosen few' at CERT, Purdue, and now apparantly 8lgm, who will invariably sit on it indefinitely (and of course, the crackers who by definition have the info, since they usually are the ones that make the holes painfully apparant), making sure the user.population is as dependent as possible on the favors and good graces of the elite, is going to have all these wonderful results (other than for the chosen few, of course)? I have not seen such evidence, nor has anybody else that I know of. I have only seen assertions that obscurity is a Good Thing because someone SAYS so. The sitting on of information *might* be viable IFF the information were eventually released. Experience shows it almost NEVER is (again CERT is a case in point), instead we are supposed to depend on 'blind faith' patches, and get paternalistic 'We Know Best What is Good For You' responses from the likes of CERT, Zardoz, etc when the 'blind faith' patch does not do so well and the site is nailed anyway. Assuming the patch is ever made, instead of the usual "We'll fix it in the next release, sometime next year...", of course. As to a verifiable incident (and a super-glaring one at that), I can recall the u-struct bug in SysVr3, where any process could write to the ruid, rgid, euid, egid elements, and become root? I recaall that bug was known for at LEAST a couple of YEARS, and was not acted upon until full disclosure forced the issue. It doesn't take a rocket scientist to figure out there were other holes not quite so blatent that were never fixed. How long has the V7 bin/mail been around? How long has the BSD mail system been around? What about rdist? What about arp? What about /bin/passwd? What about comsat? What about finger? What about LD_LIBRARY_PATH or LD_PRELOAD? Ad nauseum. Are we to believe these are ALL only RECENT holes? I betcha the holes affecting these and other parts of the system have been known to 'inner circles' for ages, some for years at least, and have only become known to the 'common folk' THROUGH the full disclosure you wish to curtail and are only NOW being fixed because of that disclosure. Till then, people could only scratch heads and do full restores after a breach that most folks would not have any idea how they were accomplished (and get paternalistic platitudes from the likes of CERT and others favoring obscurity). Most folks cannot even INSPECT for possible holes, not with source code so prohibitively priced, even for source to stuff highly probable to be subject to holes (all stuff running as root via SUID or stuff that controls entry into the site). But once a hole and attack is KNOWN, one can work to port BSD source to their OS and at least be empowered to TRY to do somehting about it. And it usually works, since there are usually many talented folks also working on the same problem. This cannot happen with your approach, Spafford. And those holes that wern't known, but only recently discovered, are we to believe the continued blissful ignoance of the hole is beieficial?! The crackers are not so charitable. They will happily exploit a hole while all the nay-sayers pontificate and spew platitudes. Now, granted, Sun is more proactive in chasing down holes and getting SOMETHING out than most, but some (too many) vendors will deny such a thing as a bug exists in THEIR code until their face gets rubbed in it. And that scares me when I have to use another vendor or a different OS that has not been hammered on as thoroughly as SunOS. We all know there are cracker types that have nothing better to do than try to find holes, and there are some that do manage to get source to aid their endavors. Full disclosure is one of the things that levels the field a bit. All the resons I can come up with for not supporting discosure are not very nice. If a workaround exists (turning off SUID bits, turning off the serivece in question if possible), there is no reason on earth for this obscurity game, save for some egos and power/turf trips. Things like urestore, suid_exec, and such are NOT critical services (and suid_exec is hardly new, either). Most of that stuff is mainly convenience, and the holes have been around for some time, but forcing a person to blindly turn them ALL off or be vulnerable is unreasonable. What is the excuse for the obscurity game regarding suid_exec? Don't tell me that its a brand new hole, I ain't buying - I heard of it (CERT style tell you nothing reference) years ago. Still dunno how to TEST how it works, thanks to the paternalistic crowd (I disable it anyway, as I don't like the idea of SUID scripts). Something like mail, a needed service, MIGHT warrant a more careful disclosure procedure, to ensure a fix of some kind (like mail_local.c that has been fixed up and posted) is easily availalble, IFF no workaround exists (like populating the mail spool with mailboxes and not deleting them, especially system accounts). But what I hear is the policcy of NEVER disclosing all the details, instead forcing the hapless site operators to be totally dependent on the 'privileged few' or on a 'blind faith' black box. Somehow I suspect you, Spafford, would not go for that idea for one second if you were not one of the few who is privy to the full details. Playing the "I got a secret and you don't" game only ensures that site operators are unable to verify the status of their sites, or check a fix they devise, often using publically available sources. Or even verify if a 'blind faith' patch really works as advertised. And what is wrong with full disclosure, at least enough info so one can test his site, if a fix is included, and also has preceeded it by, say, a week? The /bin/mail bug is a case in point of bugs that would still be there had they not been well-disclosed. Ditto the rdist hole. An advisory that says "A vulnerability exists in foo", OS Type <some vague generallity or reference to all versions here> not only denies operators the info needed to make AND POST a fix, even if its specific for their platform, but it also denies the ability of the user community to determine WHAT os's and versions are actually affected (does it affect MY site?). Such advisories are almost a taunt. Are we to believe this 8lgm bunch has the means to test all the platforms out there themselves? Somehow, I doubt it when their list of OS types in their now useless-as-CERT advisories is as vague as it is. Unless one has been nailed, asking the vendor is going to get a "No, its not a problem", or "we dunno". I wonder who 'got to them'? I wonder if it was the same person who tried to shut down an anonymous mailer in Finland? And what was offered in return for them playing the cloak-and-dagger game? Or did some net.personalities who felt they might be losing their lock on the information threaten them somehow? Like using influence to get their feeds cut off or some such thing? Or did 8lgm get included in the 'inner crowd' on condition they no longer inform the user community? That thought makes me nervous, as the 8lgm bunch's previous background was not so sterling as I understand it. Spaf, you aint lived till you get nailed and are met with a stonewall of self-righteous and paternalistic folks denying you information that could have either PREVENTED the breakin or minimized its impact. I suspect if you have had to endure that frustration, your position would be considerably different. The net.equivilant of "take 2 aspirin and call again tomorrow" (set good perms, do lots of backups and pray) just does not cut it. When someone cracks root, good perms mean diddly-squat. And good backups do not restore the work lost since the last backup, nor do they restore the lost time in cleaning up the mess, not to mention the resultant denial of service. All it takes is some bozo to 'cat /dev/zero >/dev/rsd0c' or do a 'yes >/dev/rsd0c' to ruin your whole day. Perms or restrictive mounts (like readonly, nosuid) don't help here. The sites that don't get the word don't get it due to their own choosing, not because someone is playing God and denying the info: Assuming they are connected to the net (which is the main exposure of risk), there is nothing preventing them from watching the security newsgroups or lacking news, subscribing to the mailing lists. Net.access is not needed for the latter - only an e-mail feed. The idea that the bulk of the net.population should be denied useful info regarding problems so they are able to see if their site is affected is reprehensable. If I went by the info in all those posts that don't even give a good idea as to WHAT is affected, one would have to disconnect their sites to cover all the listed problems. 8lgm was a breath of fresh air until SOMEONE got to them. I think they or someone who knows should inform the community as to who got to them, and how. I don't expect this to be revealed, because I suspect it is in the form of a threat of some kind - loss of feed, SOMETHING. I do know one thing: When myself and co-workers find time to go over a new OS and platform we are getting trying to find vulnerablilities and close them, with the current state of affairs, CERT, the Zardos crowd, and now 8lgm will be the LAST people informed. Our procedure will be to first notify the vendor, post a partial (warning level) description suggesting a workaround or fix if possible, then followed a week later by sufficient info to verify the problem on one;s own site. Folks like CERT, 8lgm, et al will get their info like everyone else. I see no reason to make an effort to send information to a black hole. The only way I would sit on info is if someone supplied it to me, and made witholding it a condition. Given the current state of affairs, (the push to tell nobody nuthin') the chance of that happening is virtually zero. All this makes me think of the elitist "Trust Us - We Know Best" mentality I have noticed is so prevalant in the Clinton Administration and their supporters. Ranging from banning this, banning that, controlling this, controlling that, denial of information to the public, granting Big Brother snoop powers to agencies, the whole nine yards. Its the MINDSET. > --spaf -- pat@rwing [If all fails, try: rwing!pat@eskimo.com] Pat Myrto - Seattle WA "No one has the right to destroy another person's belief by demanding empirical evidence." -- Ann Landers, nationally syndicated advice columnist and Director at Handgun Control Inc.